home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1126 < prev    next >
Encoding:
Text File  |  1996-08-06  |  5.1 KB  |  158 lines
  1. Path: telepost.no!usenet
  2. From: Carsten Arnholm <ca@sesam.dnv.no>
  3. Newsgroups: comp.lang.c++,comp.lang.fortran
  4. Subject: Re: Calling Fortran in C++
  5. Date: 9 Jan 1996 13:48:54 GMT
  6. Organization: DNV
  7. Message-ID: <4ctro6$28n@nms.telepost.no>
  8. References: <4cr87l$794$1@mhafc.production.compuserve.com> <4crisr$v3u@odin.sunquest.com>
  9. NNTP-Posting-Host: hugin.sesam.dnv.no
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.1 (Windows; I; 32bit)
  14.  
  15. Dean Schulze <schulze@vega.lpl.arizona.edu> wrote:
  16. >
  17. >    I recently began moving my C++/C/F77 code from
  18. >SunOS to Windows NT using VC++4.0/PowerStation4.0.  Before
  19. >doing this I considered using gcc/g77 and chose the
  20. >Microsoft compilers after being assured by MS that mixed
  21. >language programming would work with their compilers.
  22. >After working with their compilers and reading their
  23. >documentation I now see that their claims to support
  24. >legacy code with mixed language programming are deceitful.
  25. >
  26. >    In order to mix Fortran and C/C++ with Microsoft
  27. >compilers you must wrap your Fortran subroutine/function
  28. >definitions in Microsoft specific extensions. 
  29.  
  30. What exactly do you mean ? I have done almost exactly what you
  31. describe using MS VC++ and Powerstation, and found that
  32. it was relatively easy. I did not have to modify a single 
  33. characterof my FORTRAN legacy code.
  34.  
  35. What is more problematic, is to do portable, mixed language
  36. programming in C++/F77 (i.e. portable between NT, UNIX and 
  37. VMS).
  38.  
  39. I believe I have solved this problem also, in such a way 
  40. that my C++ code is unchanged across platforms (not even 
  41. using #defines in C++ code). 
  42. My legacy FORTRAN code is of course not touched.
  43.  
  44.  
  45. >This means
  46. >a lot of recoding, adding non-standard code to my standard
  47. >code.  What makes this even worse is that Powerstation
  48. >Fortran apparently will not invoke the C Preprocessor
  49. >so I cannot do something like
  50. >
  51. >#ifdef MSFORTRAN
  52. >
  53. >    (Microsoft abortions here)
  54. >
  55. >#endif
  56. >
  57. >so that I can move the code to a non-Microsoft Fortran 
  58. >compiler.
  59.  
  60. I don't think you need recoding.
  61.  
  62. Why would you want to do something like that when 
  63.   a) you don't have to 
  64.   b) it's complicated
  65.   c) it's a lot of work
  66.   d) it messes up your FORTRAN code in a non-portable way
  67.  
  68. >    Because of this stupidity by Microsoft I STRONGLY
  69. >RECOMMEND AGAINST DOING MIXED LANGUAGE PROGRAMMMING
  70. >WITH MICROSOFT COMPILERS.  You can get it to work if you
  71. >write enough MS specific code, but there is no good reason
  72. >to do this.  Consider using gcc/g77 instead under WinNT/95
  73. >or switching to Linux.
  74.  
  75. What has hit you .... ? As I see it, mixed language
  76. programming is EASIEST under MS VC++/Powerstation, as you
  77. can call the subroutines exactly as expected by a F77
  78. programmer. The only non-trivial problem you must solve
  79. is fortran CHARACTERs. You need to write a minimal CHARACTER
  80. class in C++. You also need to:
  81.  
  82. typedef int     INTEGER;
  83. typedef float   REAL;
  84. typedef int     LOGICAL; 
  85. #include  "character.h"   // the CHARACTER class
  86. #define  SUBROUTINE        extern "C" void __stdcall
  87. #define  INTEGER_FUNCTION  extern "C" INTEGER __stdcall
  88. #define  REAL_FUNCTION     extern "C" REAL __stdcall
  89.  
  90. now you can declare FORTRAN subroutine prototypes in C++:
  91.  
  92. SUBROUTINE MYSUB(INTEGER& I1, CHARACTER C1, INTEGER& I2);
  93.  
  94. >
  95. >    Mixed language programming is inherently non-portable,
  96. >but it is not hard to do and there is no good reason for
  97. >the stupidity that Microsoft has introduced.
  98. >
  99. >    Microsoft might end up making a Linux user out of
  100. >me yet.
  101. >
  102. >Dean Schulze
  103. >
  104.  
  105. Before you switch to Linux:
  106. My solution is portable (also to SGI), because I did the
  107. following:
  108.  
  109. a) I wrote header files for my FORTRAN libraries as described
  110.    above.
  111. b) Compiled FORTRAN code with Fortran powerstation and
  112.    created *.lib files.
  113. c) Included the *.lib files in my VC++ project
  114. d) Included the required header files in my C++ code.
  115. e) Compiled & linked: no problem
  116. d) Execution : no problem
  117.  
  118. porting to Unix:
  119.  
  120. a) Left C++ and Fortran code untouched !!
  121. b) Wrote a small C++ program that read my FORTRAN library
  122.    header files, and generated:
  123.    b.1: a platform-specific header file for the fortran
  124.         library. Here you deal with upper/lowercase names,
  125.         trailing underscores, character lengths etc.
  126.    b.2: a platform-specific *.CPP file containing inline
  127.         functions that convert from 
  128.         MYSUB(INTEGER& I1, CHARACTER C1, INTEGER& I2)
  129.         to
  130.         mysub_(int& I1, char* C1.rep, int& I2, int C1.len)
  131.  
  132.         (example above is for for SGI)
  133.  
  134. >
  135. >P.S.  I have written a tutorial introduction to mixed
  136. >language programming (C++/C/Fortran), including example
  137. >code, which I'll be glad to send to anyone who wants it.
  138. >Just e-mail me.
  139. >
  140. >    My examples are work with Sun and SGI compilers,
  141. >and will probably work without modifications for
  142. >gcc/g77 on Win32.  My examples show how easy and clean
  143. >mixed language programming is.  No Microsoft-like abortions
  144. >are needed, and they should be avoided.
  145. >
  146.  
  147.  
  148. Please send me your tutorial introduction, and if possible, 
  149. tell me where my strategy fails. 
  150.  
  151. I would actually like to hear if there is more to this 
  152. problem than what I have realised so far, but I would be
  153. surprised if there is.
  154.  
  155. Carsten Arnholm
  156. ca@sesam.dnv.no
  157.  
  158.